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Abstract 


Spiral  development  is  a  family  of  software  development  processes  characterized  by  repeat¬ 
edly  iterating  a  set  of  elemental  development  processes  and  managing  risk  so  it  is  actively 
being  reduced.  This  paper  characterizes  spiral  development  by  enumerating  a  few  “invariant” 
properties  that  any  such  process  must  exhibit.  For  each,  a  set  of  “variants”  is  also  presented, 
demonstrating  a  range  of  process  definitions  in  the  spiral  development  family.  Each  invariant 
excludes  one  or  more  “hazardous  spiral  look-alike”  models,  which  are  also  outlined.  This 
report  also  shows  how  the  spiral  model  can  be  used  for  a  more  cost-effective  incremental 
commitment  of  funds,  via  an  analogy  of  the  spiral  model  to  stud  poker.  An  important  and 
relatively  recent  innovation  to  the  spiral  model  has  been  the  introduction  of  anchor  point 
milestones.  The  latter  part  of  the  paper  describes  and  discusses  these. 


Editor’s  Note:  This  document  began  as  a  set  of  slides  prepared  and  annotated  by  Barry  Boehm  and 
presented  by  him  at  the  Spiral  Development  Workshop,  February  2000.  With  Barry’s  consent,  I  un¬ 
dertook  the  task  of  converting  these  slides  to  the  text  you  now  see.  The  original  slides  are  available  on 
the  workshop  Web  site:  http://www.sei.cmu.edu/cbs/spiral2000/Boehm. 
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1  Introduction 


This  presentation  opened  the  Workshop  on  Spiral  Development  Experience  and  Implementa¬ 
tion  Challenges  held  by  the  University  of  Southern  California  (USC)  and  the  Software  Engi¬ 
neering  Institute  (SEI)  on  February  9-11,  2000  at  USC.  The  workshop  brought  together 
leading  executives  and  practitioners  with  experience  in  spiral  development  of  software¬ 
intensive  systems  in  the  commercial,  aerospace,  and  government  sectors.  Its  objectives  were 
to  distill  the  participants’  experiences  into  a  set  of  critical  success  factors  for  implementing 
and  conducting  spiral  development,  and  to  identify  the  most  important  needs,  opportunities, 
and  actions  to  expedite  organizations’  transition  to  successful  spiral  development.  For  the 
workshop,  “development”  was  defined  to  include  life  cycle  evolution  of  software-intensive 
systems  £ind  such  related  practices  as  legacy  system  replacement  and  integration  of  commer¬ 
cial-off-the-shelf  (COTS)  components.  Although  of  greatest  utility  for  software  develop¬ 
ments,  the  spiral  model  can  also  be  used  to  develop  hardware  or  integrate  software,  hardware, 
and  systems. 

To  provide  a  starting  point  for  addressing  the  workshop  objectives,  I  have  tried  in  this  talk  to 
distill  my  experiences  in  developing  and  transitioning  the  spiral  model  at  TRW;  in  using  it  in 
system  acquisitions  at  the  Defense  Advanced  Research  Projects  Agency  (DARPA);  in  trying 
to  refine  it  to  address  problems  that  people  have  had  in  applying  it  in  numerous  commercial, 
aerospace,  and  government  contexts;  and  in  working  with  the  developers  of  major  elabora¬ 
tions  and  refinements  of  the  spiral  model  such  as  the  Software  Productivity  Consortium's 
(SPC)  Evolutionary  Spiral  Process  (SPC)  [SPC  94]  and  Rational,  Inc.’s  Rational  Unified  Pro¬ 
cess  (RUP)  [Royce  98,  Kruchten  98,  Jacobson  99].  I've  modified  the  presentation  somewhat 
to  reflect  the  experience  and  discussions  at  the  Workshop  and  this  report  is  a  further  refine¬ 
ment. 

One  of  the  findings  of  the  workshop  was  a  need  for  a  clear  and  widely  understood  definition 
of  the  spiral  development  model.  The  characteristics  of  the  model  noted  here  should  suffice 
as  a  starting  point  for  this  work. 

1 .1  Success  Stories  from  the  Workshop 

A  number  of  projects  and  project  frameworks  successfully  exploiting  the  spiral  model  were 
presented  at  the  workshop,  often  with  supplementary  material  elsewhere.  C-Bridge’s  RAPID 
approach  has  been  used  successfully  to  develop  e-commerce  applications  in  12-24  weeks.  Its 
Define,  Design,  Develop,  and  Deploy  phases  use  the  equivalent  of  the  anchor  point  mile¬ 
stones  (see  Section  2.5)  as  phase  gates  [Leinbach  00].  The  large  spiral  telecoimnunications 
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applications  discussed  in  [Bernstein  00]  and  [DeMillo  00]  use  a  complementary  best  practice 
as  their  anchor  point  milestones:  the  AT&T/Lucent/Telcordia  Architecture  Review  Board  pro¬ 
cess  [AT&T  93].  Xerox’s  Time-to-Market  process  uses  the  anchor  point  milestones  as  hard¬ 
ware-software  synchronization  points  for  its  printer  business  line  [Hantos  00], 

Several  successful  large  aerospace  spiral  projects  were  also  discussed.  The  best  documented 
of  these  is  the  CCPDS-R  project  discussed  in  [Royce  98].  Its  Ada  Process  Model  was  the 
predecessor  of  the  Rational  Unified  Process  and  USC  MBASE  approach,  which  have  both 
been  used  on  a  number  of  successful  spiral  projects  [Jacobson  99,  Boehm  98],  as  has  the  SPC 
Evolutionary  Spiral  Process  [SPC  94].  Further  successful  large  aerospace  spiral  projects 
were  presented  by  SAIC  and  TRW  [Kitaoka  00,  Bostelaar  00]. 
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1.2  The  Spiral  Development  Model 

Figure  1  is  a  redrawing  of  the  original  spiral  model  diagram  published  by  Boehm  [Boehm 
88].  It  captures  the  major  spiral  model  features:  cyclic  concurrent  engineering;  risk  driven 
determination  of  process  and  product;  growing  a  system  via  risk-driven  experimentation  and 
elaboration;  and  lowering  development  cost  by  early  elimination  of  nonviable  alternatives 
and  rework  avoidance.  As  a  result  of  planning  and  risk  analysis,  different  projects  may 
choose  different  processes.  That  is,  the  spiral  model  is  actually  a  risk-driven  process  model 
generator,  in  which  different  risk  patterns  can  lead  to  choosing  incremental,  waterfall,  evolu¬ 
tionary  prototyping,  or  other  subsets  of  the  process  elements  in  the  spiral  model  diagram. 


For  a  number  of  reasons,  however,  the  spiral  model  is  not  universally  understood.  For  in¬ 
stance,  Figure  1  contains  some  oversimplifications  that  have  caused  a  number  of  misconcep¬ 
tions  to  propagate  about  the  spiral  model.  These  misconceptions  may  fit  a  few  rare  risk  pat¬ 
terns,  but  are  definitely  not  true  for  most  risk  patterns.  The  most  significant  misconceptions 
to  avoid  are:  that  the  spiral  is  just  a  sequence  of  waterfall  increments;  that  everything  on  the 
project  follows  a  single  spiral  sequence;  that  every  element  in  the  diagram  needs  to  be  visited 
in  the  order  indicated;  and  that  there  can  be  no  backtracking  to  revisit  previous  decisions.  In 
addition  to  these  misconceptions,  other  similar — but  hazardously  distinct — ^processes  have 
been  held  up  as  spiral  processes. 

To  promote  understanding  and  effective  use  of  the  spiral  model,  this  report  more  precisely 
characterizes  the  spiral  model.  We  begin  with  a  simple  overview  definition  to  capture  the 
essence  of  the  model: 

The  spiral  development  model  is  a  mfc-driven  process  model  generator. 

It  is  used  to  guide  multi-stakeholder  concurrent  engineering  of  software¬ 
intensive  systems.  It  has  two  main  distinguishing  features.  One  is  a 
cyclic  approach  for  incrementally  growing  a  system’s  degree  of 
definition  and  implementation  while  decreasing  its  degree  of  risk.  The 
other  is  a  set  of  anchor  point  milestones  for  ensuring  stakeholder 
commitment  to  feasible  and  mutually  satisfactory  system  solutions. 

Risks  are  situations  or  possible  events  that  can  cause  a  project  to  fail  to  meet  its  goals, 
They  range  in  impact  from  trivial  to  fatal  and  in  likelihood  from  certain  to  improb¬ 
able.  A  risk  management  plan  enumerates  the  risks  and  prioritizes  them  in  degree  of 
importance,  as  measured  by  a  combination  of  the  impact  and  likelihood  of  each.  For 
each  risk  the  plan  also  states  a  mitigation  strategy  to  deal  with  the  risk.  For  instance, 
the  risk  that  technology  is  unready  may  be  mitigated  by  an  appropriate  prototype  im¬ 
plementation  in  an  early  spiral  cycle. 

A  process  model  answers  two  main  questions: 

•  What  should  be  done  next? 
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•  For  how  long  should  it  continue? 

Under  the  spiral  model  the  answers  to  these  questions  are  driven  by  risk  considerations  and 
vary  from  project  to  project  and  sometimes  from  one  spiral  cycle  to  the  next.  Each  choice  of 
answers  generates  a  different  process  model.  At  the  start  of  a  cycle,  all  of  the  project’s  suc¬ 
cess-critical  stakeholders  must  participate  concurrently  in  reviewing  risks  and  choosing  the 
project’s  process  model  accordingly.  (Risk  considerations  also  apply  toward  to  ensuring  that 
progress  is  not  impeded  by  stakeholders’  overparticipation). 

The  cyclic  nature  of  the  spiral  model  was  illustrated  in  Figure  1 . 

Anchor  point  milestones  drive  the  spiral  to  progress  toward  completion  and  offer  a  means  to 
compare  progress  between  one  spiral  project  and  another.  The  second  half  of  the  report  ex¬ 
pands  on  these  milestones.  It  also  presents  some  experience-based  refinements  of  the  spiral 
model  developed  to  address  spiral  usage  problems  encountered  over  the  years:  evolutionary 
development,  Rational  Unified  Process  (RUP),  the  Win  Win  spiral  model,  and  the  Model- 
Based  (System)  Architecting  and  Software  Engineering  (MBASE)  approach. 

The  spiral  development  model  is  more  precisely  characterized  in  the  next  section  with  invari¬ 
ant  properties  and  their  variants.  Invariant  5  invokes  the  relatively  new  concept  of  “anchor 
point  milestones.”  These  are  considered  in  more  depth  in  the  third  section.  The  fourth  section 
presents  tables  summarizing  the  material. 
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2  The  Invariants  and  Their  Variants 


Those  successfully  following  the  spiral  model  discipline  will  find  that  their  cycles  invariantly 
display  these  six  characteristics: 

1.  Concurrent  rather  than  sequential  determination  of  artifacts. 

2.  Consideration  in  each  spiral  cycle  of  the  main  spiral  elements: 

-  critical-stakeholder  objectives  and  constraints 

-  product  and  process  alternatives 

-  risk  identification  and  resolution 

-  stakeholder  review 

-  commitment  to  proceed 

3.  Using  risk  considerations  to  determine  the  level  of  effort  to  be  devoted  to  each  activity 
within  each  spiral  cycle. 

4.  Using  risk  considerations  to  determine  the  degree  of  detail  of  each  artifact  produced  in 
each  spiral  cycle. 

5.  Managing  stakeholder  life-cycle  commitments  with  three  anchor  point  milestones: 

-  Life  Cycle  Objectives  (LCO) 

-  Life  Cycle  Architecture  (LCA) 

-  Initial  Operational  Capability  (IOC) 

6.  Emphasis  on  activities  and  artifacts  for  system  and  life  cycle  rather  than  for  software 
and  initial  development. 

Subsequent  sections  describe  each  of  these  invariants,  the  critical-success-factor  reasons  why 
it  is  an  essential  invariant,  and  its  associated  optional  variants.  Examples  are  given,  including 
an  analogy  with  stud  poker  which  demonstrates  how  the  spiral  model  accommodates  cost- 
effective  incremental  commitment  of  funds.  Many  processes  are  adopted  which  may  seem  to 
be  instances  of  the  spiral  model,  but  lack  essential  invariants  and  thus  risk  failure.  Each  in¬ 
variant  excludes  one  or  more  such  process  models,  which  we  call  “hazardous  spiral  look- 
alikes.”  They  are  cataloged  and  pilloried  as  part  of  describing  the  invariants. 
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2.1  Spiral  invariant  1 :  Concurrent  Determination  of 
Key  Artifacts  (Ops  Concept,  Requirements,  Plans, 
Design,  Code) 

Spiral  Invariant  1  states  that  it  is  success-critical  to  concurrently  determine  a  compatible  and 
feasible  combination  of  key  artifacts:  the  operational  concept,  the  system  and  software  re¬ 
quirements,  the  plans,  the  system  and  software  architecture  and  design,  and  the  key  code 
components  including  COTS,  reused  components,  prototypes,  success-critical  components, 
and  algorithms. 


Summary  of  Invariant  1 

Whyinvariant  : 

avoids  premature  sequential  commitments  to 
system  requirements,  design,  COTS, 

combination  of  cost  /  schedule  /  performance  s  .^Y ; : 
Example:  "one  second  response  time" 

Variants  ' 

la.  Relative  amount  of  each  artifact  developed  in  each  cycle 

lb.  Number  of  concurrent  mini-cycles  In  each  cycle  V  f 

Models  excluded 

Incremental  sequential  waterfalls 

with  high  risk  of  violating  waterfall  model  assumptions 


Why  is  this  a  success-critical  invariant?  Because  sequential  determination  of  the  key  artifacts 
will  prematurely  overconstrain,  and  often  extinguish,  the  possibility  of  developing  a  system 
which  satisfies  the  stakeholders’  essential  success  conditions.  Examples  are  premature  com¬ 
mitments  to  hardware  platforms,  to  incompatible  combinations  of  COTS  components  [Garlan 
95],  and  to  requirements  whose  achievability  has  not  been  validated,  such  as  the  one-second 
response  time  requirement  Example  just  below. 

Variants  la  and  lb  indicate  that  the  product  and  process  internals  of  the  concurrent  engineer¬ 
ing  activity  are  not  invariant.  For  a  low  technology,  interoperability-critical  system,  the  ini¬ 
tial  spiral  products  will  be  requirements-intensive.  For  a  high-technology,  more  standalone 
system,  the  initial  spiral  products  will  be  prototype  code-intensive.  Also,  there  is  no  invariant 
number  of  mini-cycles  (e.g.,  individual  prototypes  for  COTS,  algorithm,  or  user-interface 
risks)  within  a  given  spiral  cycle. 
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Example:  One-Second  Response  Time 


Figure  2  provides  an  example  of  the  kinds  of  problems  that  occur  when  high-risk  require¬ 
ments  are  prematurely  frozen.  In  the  early  1980s,  a  large  government  organization  contracted 
with  TRW  to  develop  an  ambitious  information  system.  The  system  would  provide  more 
than  a  thousand  users,  spread  across  a  large  building  complex,  with  powerful  query  and 
analysis  capabilities  for  a  large  and  dynamic  database. 


TRW  and  the  customer  specified  the  system  using  a  classic  sequential-engineering  waterfall 
development  model.  Based  largely  on  user  need  surveys  and  an  oversimplified  high-level 
performance  analysis,  they  fixed  into  the  contract  a  requirement  for  a  system  response  time  of 
less  than  one  second. 

Two  thousand  pages  of  requirements  later,  the  software  architects  found  that  subsecond  per¬ 
formance  could  only  be  provided  via  Architecture  A,  a  highly  customized  design  that  at¬ 
tempted  to  anticipate  query  patterns  and  cache  copies  of  data  so  that  each  user’s  likely  data 
would  be  within  one  second’s  reach.  The  resulting  hardware  architecture  had  more  than  25 
super-minicomputers  busy  caching  data  according  to  algorithms  whose  actual  performance 
defied  easy  analysis.  The  scope  and  complexity  of  the  hardware-software  architecture 
brought  the  estimated  cost  of  the  system  to  nearly  $100  million,  driven  primarily  by  the  re¬ 
quirement  for  a  one-second  response  time. 

Faced  with  this  unattractive  prospect,  the  customer  and  developer  decided  to  develop  a  pro¬ 
totype  of  the  system’s  user  interface  and  representative  capabilities  to  test.  The  results 


CMU/SEI-2000-SR-008 


7 


showed  that  a  four-second  response  time  would  satisfy  users  90  percent  of  the  time.  A  four- 
second  response  time  could  be  achieved  with  Architecture  B,  cutting  development  costs  to 
$30  million  [Boehm  OOa],  Thus,  the  premature  specification  of  a  one-second  response  time 
inserted  the  hidden  risk  of  creating  an  overly  expensive  and  time-consuming  system  devel¬ 
opment. 

Hazardous  Spiral  Look-Alike:  Violation  of  Waterfall  Assumptions 

Invariant  1  excludes  one  model  often  labeled  as  a  spiral  process,  but  which  is  actually  a  “haz¬ 
ardous  spiral  look-alike.”  This  is  the  use  of  a  sequence  of  incremental  waterfall  developments 
with  a  high  risk  of  violating  the  underlying  assumptions  of  the  waterfall  model.  These  as¬ 
sumptions  are 

1 .  The  requirements  are  knowable  in  advance  of  implementation. 

2.  The  requirements  have  no  unresolved,  high-risk  implications,  such  as  risks  due  to 
COTS  choices,  cost,  schedule,  performance,  safety,  security,  user  interfaces,  and 
organizational  impacts. 

3.  The  nature  of  the  requirements  will  not  change  very  much  either  during  development  or 
evolution. 

4.  The  requirements  are  compatible  with  all  the  key  system  stakeholders’  expectations, 
including  users,  customer,  developers,  maintainers,  investors. 

5.  The  right  architecture  for  implementing  the  requirements  is  well  understood. 

6.  There  is  enough  calendar  time  to  proceed  sequentially. 

These  assumptions  must  be  met  by  a  project  if  the  waterfall  model  is  to  succeed.  If  all  of 
these  are  true,  then  it  is  a  project  risk  not  to  specify  the  requirements,  and  the  waterfall  model 
becomes  a  risk-driven  special  case  of  the  spiral  model.  If  any  of  the  assumptions  are  untrue, 
then  specifying  a  complete  set  of  requirements  in  advance  of  risk  resolution  will  commit  a 
project  to  assumptions/requirements  mismatches  that  will  lead  the  project  into  trouble. 

Assumption  1 — the  requirements  are  knowable  in  advance  of  implementation — is  generally 
untrue  for  new  user-interactive  systems,  because  of  the  IKIWISI  syndrome.  When  asked  for 
their  required  screen  layout  for  a  new  decision-support  system,  users  will  generally  say,  “I 
can’t  tell  you,  but  I’ll  know  it  when  I  see  it  (IKIWISI).”  In  such  cases,  a  concurrent 
prototyping/requirements/architecture  approach  is  essential. 

The  effects  of  invalidity  in  Assumptions  2,  4,  and  5  are  well  illustrated  by  the  example  in 
Figure  2.  The  one-second  response  time  requirement  was  unresolved  and  high-risk.  It  was 
compatible  with  the  users’  expectations,  but  not  with  the  customer’s  budget  expectations. 

And  the  need  for  an  expensive  custom  architecture  was  not  understood  in  advance. 

The  effects  of  invalidity  in  Assumptions  3  and  6  are  well  illustrated  by  electronic  commerce 
projects.  In  these  projects  the  volatility  of  technology  and  the  marketplace  is  so  high  that  re¬ 
quirements  and  traceability  updates  will  swamp  the  project  in  overhead.  Furthermore,  the 
amount  of  initial  calendar  time  it  takes  to  work  out  a  complete  set  of  detailed  requirements 
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that  are  likely  to  change  several  times  downstream  is  not  a  good  investment  of  the  scarce  time 
to  market  available  to  develop  an  initial  operational  capability. 

2.2  Spiral  Invariant  2:  Each  Cycle  Does  Objectives, 
Constraints,  Alternatives,  Risks,  Review, 
Commitment  to  Proceed 

Spiral  Invariant  2  identifies  the  activities  in  each  quadrant  of  the  original  spiral  diagram  that 
need  to  be  done  in  each  spiral  cycle.  These  include  consideration  of  critical-stakeholder  ob¬ 
jectives  and  constraints;  elaboration  and  evaluation  of  project  and  process  alternatives  for 
achieving  the  objectives  subject  to  the  constraints;  identification  and  resolution  of  risks  atten¬ 
dant  on  choices  of  alternative  solutions;  and  stakeholders’  review  and  commitment  to  proceed 
based  on  satisfaction  of  their  critical  objectives  and  constraints.  If  all  of  these  are  not  consid¬ 
ered,  the  project  may  be  prematurely  committed  to  alternatives  that  are  either  unacceptable  to 
key  stakeholders  or  overly  risky. 


Summary  of  Invariant  2 

'  Why  invarlant;;S?Sf 

!  Avoids  conynlltnentto  ^talwholder*unacceptabla 


or  overivnsky  alternatives.  ,  :  ■  ^  . 

Avoids  wa8t|d:effort  in  elaboratliijS  urisatisftictp^|aitai|hn^ti^^iis 
Exampie:  "Vinnciows-oniyCO'TS”-^.;  ^ -.b  It''-:,'..'.."  ■ 


Variants 

2a. 


prototyping,  simulation,  modeling,  l>enchmai^n|£^';C^f^^^^ 
reference.checking,  etc.  ,  .f' 

2b.  Level  of  effort  on  each  actiyii|^iMjthin  each  cycle  f  ? 

Sequential  phases  with  key  stak^bideis  excluded 


Models  excluded  * 


Project  groups  must  also  guard  against  having  the  appearance  but  not  the  reality  of 
stakeholder  participation  by  accepting  an  unqualified  member  of  an  integrated  product  team 
(IPT).  A  good  set  of  criteria  for  qualified  IPT  members — as  described  in  Boehm  and  adopted 
in  USAF  [Boehm  98,  USAF  00] — ^is  to  ensure  that  IPT  members  are  representative  (of  or¬ 
ganizational  rather  than  personal  positions),  empowered  (to  make  commitments  which  will  be 
honored  by  their  organizations),  knowledgeable  (of  their  organization's  critical  success  fac¬ 
tors),  collaborative,  and  committed. 

Spiral  Invariant  2  does  not  mandate  particular  generic  choices  of  risk  resolution  techniques. 
However,  there  are  risk  management  guidelines  that  suggest,  for  example,  the  best-candidate 
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risk  resolution  techniques  for  the  major  sources  of  project  risk  [Boehm  89a].  This  invariant 
also  does  not  mandate  particular  levels  of  effort  for  the  activities  performed  during  each  cy¬ 
cle.  Levels  must  be  balanced  between  the  risks  of  learning  too  little  and  the  risks  of  wasting 
time  and  effort  gathering  marginally  useful  information. 

Example:  Windows-Only  COTS 

Ignoring  Invariant  2,  can  lead  to  a  good  deal  of  wasted  effort  in  elaborating  an  alternative  that 
could  have  been  shown  earlier  to  be  unsatisfactory.  One  of  the  current  USC  digital  library 
projects  is  developing  a  web-based  viewer  for  oversized  artifacts  (e.g.,  newspapers,  large  im¬ 
ages).  The  initial  prototype  featured  a  tremendously  powerful  and  high-speed  viewing  capa¬ 
bility,  based  on  a  COTS  product  called  ER  Mapper.  The  initial  project  review  approved  se¬ 
lection  of  this  COTS  product,  even  though  it  only  ran  well  on  Windows  platforms,  and  the 
Library  had  significant  Macintosh  and  UNIX  user  communities.  This  decision  was  based  on 
initial  indications  that  Mac  and  UNIX  versions  of  ER  Mapper  would  be  available  soon. 

However,  subsequent  investigations  indicated  that  it  would  be  a  long  time  before  such  Mac 
and  UNIX  capabilities  would  become  available.  At  a  subsequent  review,  ER  Mapper  was 
dropped  in  favor  of  a  less  powerful  but  fully  portable  COTS  product,  Mr.  SID,  but  only  after 
a  good  deal  of  effort  was  wasted  on  elaborating  the  ER  Mapper  solution.  If  a  representative 
of  the  Mac  or  UNIX  user  community  had  been  involved  in  the  early  project  decisions,  the 
homework  leading  to  choosing  Mr.  SID  would  have  been  done  earlier,  and  the  wasted  effort 
in  elaborating  the  ER  Mapper  solution  would  have  been  avoided. 

Hazardous  Spiral  Look-Alike:  Excluding  Key  Stakeholders 

Excluded  by  Invariant  2  is  another  “hazardous  spiral  look-alike”:  organizing  the  project  into 
sequential  phases  or  cycles  in  which  key  stakeholders  are  excluded.  Examples  are  excluding 
developers  from  system  definition,  excluding  users  from  system  construction,  or  excluding 
system  maintainers  from  either  definition  or  construction. 


User, 

Customer 

Customer, 

Developer 

Developer, 

User,  Maintainer 

^  Inception  ^ 

Elaboration 
Construction  ^ 

Transition 

i _ 

Figure  3:  Models  Excluded:  Sequential  Phases  without  Key  Stakeholders 
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Even  though  the  phases  shown  in  Figure  3  may  look  like  risk-driven  spiral  cycles,  this  spiral 
look-alike  will  be  hazardous  because  its  exclusion  of  key  stakeholders  is  likely  to  cause  criti¬ 
cal  risks  to  go  undetected.  Excluding  developer  participation  in  early  cycles  can  lead  to 
project  commitments  based  on  unrealistic  assumptions  about  developer  capabilities.  Ex¬ 
cluding  users  or  maintainers  from  development  cycles  can  lead  to  win-lose  situations,  which 
generally  evolve  into  lose-lose  situations  [Boehm  89b]. 


2.3  Spiral  Invariant  3:  Level  of  Effort  Driven  by  Risk 
Considerations 

Spiral  Invariant  3  dictates  the  use  of  risk  considerations  to  answer  the  difficult  questions  of 
how-much-is-enough  of  a  given  activity.  How  much  is  enough  of  domain  engineering? 
prototyping?  testing?  configuration  management?  and  so  on. 


SumiTfiarv  of  Invariant  3 


Why  invariant 

Oeterminea  “how  much  isonough”  of  eadhacttvity:  ... 
domain  ohpinMHng,  prototyping,  testing,  CM,  etok.v  « 

Avoids  ove^iii  dp  heiat^  risk  resolution 

,  , ;  ,  '  *  ,  : "  . . . 

Exampte:  PnB>ship  tostinj 
^Variants 


3a."  Choice'  di'mdtii6dliksed'to;dur8ue  activitiiw:i>*^^f'i' 
MBASEfWinWin,  Rational  RUP;  JAD;  QFD,«SP, ; . . 
3b.  Degree  of  detail  of  artifacts  jiroduced  in  each dycie ; 

V  ''L'  n  ^  >’v''  ’  '  '  ”  '  ' 

Models  excluded  W’  ■ 


Risk’-insehsidveevoli^ibnairy  dr  iricremental  deyel^pn^t  S; 


If  you  plot  a  project’s  risk  exposure  as  a  function  of  time  spent  prototyping,  there  is  a  point  at 
which  risk  exposure  is  minimized.  Spending  significantly  more  time  than  this  is  an  overkill 
leading  to  late  market  entry  and  decreased  market  penetration.  Spending  significantly  less 
time  prototyping  is  an  underkill,  leading  to  premature  development  with  significant  delays 
due  to  unanticipated  snags.  Given  that  risk  profiles  vary  from  project  to  project,  this  means 
that  the  risk-minimizing  level  of  prototyping  effort  will  vary  from  project  to  project.  The 
amount  of  effort  devoted  to  other  activities  will  also  vary  as  a  function  of  a  project’s  risk  pro¬ 
file. 

Variants  to  be  considered  include  the  choice  of  methods  used  to  pursue  activities  (e.g., 
MBASEAVinWin,  Rational  RUP,  JAD,  QFD,  ESP)  and  the  degree  of  detail  of  artifacts  pro- 
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duced  in  each  cycle.  Another  variant  is  an  organization’s  choice  of  particular  methods  for  risk 
assessment  and  management. 

Example;  Pre-Ship  Testing 

Figure  4  shows  how  risk  considerations  can  help  determine  “how  much  testing  is  enough” 
before  shipping  a  product.  This  can  be  determined  by  adding  up  the  two  main  sources  of 
Risk  Exposure,  RE  =  Probability  (Loss)  •  Size  (Loss),  incurred  by  two  sources  of  loss:  loss  of 
profitability  due  to  product  defects,  and  loss  of  profitability  due  to  delays  in  capturing  market 
share.  The  more  testing  that  is  done,  the  lower  becomes  the  risk  exposure  due  to  defects,  as 
discovered  defects  reduce  both  the  size  of  loss  due  to  defects  and  the  probability  that  undis¬ 
covered  defects  still  remain.  However,  the  more  time  spent  testing,  the  higher  are  both  the 
probability  of  loss  due  to  competitors  entering  the  market  and  the  size  of  loss  due  to  de¬ 
creased  profitability  on  the  remaining  market  share. 


Figure  4:  Pre-Ship  Test  Risk  Exposure 


As  shown  in  Figure  4,  the  sum  of  these  risk  exposures  achieves  a  minimum  at  some  interme¬ 
diate  level  of  testing.  The  location  of  this  minimum-risk  point  in  time  will  vary  by  type  of 
organization.  For  example,  it  will  be  considerably  shorter  for  a  “dot.com”  company  than  it 
will  for  a  safety-critical  product  such  as  a  nuclear  power  plant.  Calculating  the  risk  exposures 
also  requires  an  organization  to  accumulate  a  fair  amount  of  calibrated  experience  on  the 
probabilities  and  size  of  losses  as  functions  of  test  duration  and  delay  in  market  entry. 

Hazardous  Spiral  Look-Alikes:  Risk  insensitivity 

Hazardous  spiral  model  look-alikes  excluded  by  Invariant  3  are 

•  risk-insensitive  evolutionary  development 

(e.g.,  neglecting  scalability  risks) 

•  risk-insensitive  incremental  development 

(e.g.,  suboptimizing  on  increment  1  with  a  point-solution  architecture  which  must 
be  dropped  or  heavily  reworked  to  accommodate  future  increments) 

•  impeccable  spiral  plans  with  no  commitment  to  managing  the  risks  identified. 
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2.4  Spiral  Invariant  4:  Degree  of  Detail  Driven  by  Risk 
Considerations 


Spiral  Invariant  4  is  the  product  counterpart  of  Invariant  3:  that  risk  considerations  determine 
the  degree  of  detail  of  products  as  well  as  processes.  This  means,  for  example,  that  the  tradi¬ 
tional  ideal  of  a  complete,  consistent,  traceable,  testable  requirements  specification  is  not  a 
good  idea  for  certain  product  components,  such  as  a  graphic  user  interface  (GUI)  or  COTS 
interface.  Here,  the  risk  of  precisely  specifying  screen  layouts  in  advance  of  development 
involves  a  high  probability  of  locking  an  awkward  user  interface  into  the  development  con¬ 
tract,  while  the  risk  of  not  specifying  screen  layouts  is  low,  given  the  general  availability  of 
flexible  GUI-builder  tools.  Even  aiming  for  full  consistency  and  testability  can  be  risky,  as  it 
creates  a  pressure  to  prematurely  specify  decisions  that  would  better  be  deferred  (e.g.,  the 
form  and  content  of  exception  reports).  However,  some  risk  patterns  make  it  very  important 
to  have  precise  specifications,  such  as  the  risks  of  safety-critical  interface  mismatches  be¬ 
tween  hardware  and  software  components,  or  between  a  prime  contractor’s  and  a  subcon¬ 
tractor’s  software. 


Surnmarv  of  Invariant  4 

'Whyinvariant  . . ; 


Delennine8  :!‘how  mudi  Is  jenough’*  of  each  artHtect 

— '“nmentB^Design,  Code,  Plans)  jiweacH  cycle  ‘  ! 


Avoids  overkill  or  telat^  risk  resolution  ? 
.Example;  Hiel^of  P(iecl^^pecification 
^^Variante  > 


Models  excitiMed 


I 


arl  ' 


''^T:fl!^ii^lete$i>i»iit|$i^ac(^bie^"testable%ldtdi^ 
""t'^spjKidicatlonfoit'Syst^sinyblving’sIgnlfle^iht,^^^^^ 

; '"GUI,  COTS,' dr defen^ decisions  '' 


This  guideline  shows  when  it  is  risky  to  over-specify  and  under-specify  software  features: 

•  If  it's  risky  to  not  specify  precisely,  DO  specify 

(e.g.,  hardware-software  interface,  prime-subcontractor  interface) 

•  If  it's  risky  to  specify  precisely,  DO  NOT  specify 

(e.g.,  GUI  layout,  COTS  behavior) 

Spiral  variants  related  to  Invariant  4  are  the  choices  of  representations  for  product  artifacts. 
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Example:  Risk  of  Precise  Specification 

One  editor  specification  required  that  every  operation  be  available  through  a  button  on  the 
window.  As  a  result,  the  space  available  for  viewing  and  editing  became  unusably  small.  The 
developer  was  precluded  from  moving  some  operations  to  menus  because  the  GUI  layout  had 
been  specified  precisely  at  an  early  step.  (Of  course,  given  too  much  freedom  programmers 
can  develop  very  bad  GUIs.  Stakeholder  review  is  essential  to  avoid  such  problems.) 


2.5  Spiral  Invariant  5:  Use  of  Anchor  Point  Milestones: 
LCO,  LCA,  IOC 

A  major  difficulty  of  the  original  spiral  model  was  its  lack  of  intermediate  milestones  to  serve 
as  commitment  points  and  progress  checkpoints  [Forsberg  96].  This  difficulty  has  been  reme¬ 
died  by  the  development  of  a  set  of  anchor  point  milestones:  Life  Cycle  Objectives  (LCO), 
Life  Cycle  Architecture  (LCA),  and  Initial  Operational  Capability  (IOC)  [Boehm  96].  These 
can  be  described  as  stakeholder  commitment  points  in  the  software  life  cycle:  LCO  is  the 
stakeholder’s  commitment  to  support  architecting;  LCA  is  the  stakeholders'  commitment  to 
support  full  life  cycle;  and  IOC  is  the  stakeholders'  commitment  to  support  operations. 


Summary  of  Invariant  5 


Why  invariant  :  -  ^  ;  :  ^ 

Avoids  analysis  paraiysis,  unrealistic  expectations, 

requirements  creep,  architectural  drift,  COTS  shortfalls 
and  incompatibilities,  unsustainable  architectures, 
traumatic  cutovers,  useless  systems  ,  ' 

Example:  Stud  Poker  Analogy  ; 

Variants  •••■'-■'a.'-.;,..,.,", 

5a.  Number  of  spiral  cycles  or  increments  between  anchor  points 
Sb.  Situation-specific  merging  of  anchor  point  milestones 

Models  excluded  —  ' ’• 


Evolutions^  or  incremental  developmaht  ^  ^ 
with  no  life  cycle  architecture 


The  anchor  point  milestones  were  defined  in  a  pair  of  USC  Center  for  Software  Engineering 
Affiliates’  workshops,  and  as  such  represent  joint  efforts  by  both  industry  and  government 
participants  [Clark  95].  One  of  the  Affiliates,  Rational,  Inc.,  had  been  defining  the  phases  of 
its  Rational  Unified  Process  (RUP),  and  adopted  the  anchor  point  milestones  as  its  phase 
gates. 
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The  first  two  anchor  points  are  the  Life  Cycle  Objectives  (LCO)  and  Life  Cycle  Architecture 
(LCA).  At  each  of  these  anchor  points  the  key  stakeholders  review  six  artifacts:  operational 
concept  description,  prototyping  results,  requirements  description,  architecture  description, 
life  cycle  plan,  and  feasibility  rationale  (see  Section  3.1  for  details). 

The  feasibility  rationale  covers  the  key  pass/fail  question:  “If  I  build  this  product  using  the 
specified  architecture  and  processes,  will  it  support  the  operational  concept,  realize  the 
prototyping  results,  satisfy  the  requirements,  and  finish  within  the  budgets  and  schedules  in 
the  plan?”  If  not,  the  package  should  be  reworked. 

The  focus  of  the  LCO  review  is  to  ensure  that  at  least  one  architecture  choice  is  viable  from  a 
business  perspective.  The  focus  of  the  LCA  review  is  to  commit  to  a  single  detailed  defini¬ 
tion  of  the  review  artifacts.  The  project  must  have  either  eliminated  all  significant  risks  or 
put  in  place  an  acceptable  risk-management  plan.  The  LCA  milestone  is  particularly  impor¬ 
tant,  as  its  pass/fail  criteria  enable  stakeholders  to  hold  up  projects  attempting  to  proceed  into 
evolutionary  or  incremental  development  without  a  life  cycle  architecture. 

The  LCO  milestone  is  the  equivalent  of  getting  engaged,  and  the  LCA  milestone  is  the 
equivalent  of  getting  married.  As  in  life,  if  you  marry  your  architecture  in  haste,  you  and 
your  stakeholders  will  repent  at  leisure.  The  third  anchor  point  milestone,  the  Initial  Opera¬ 
tional  Capability  (IOC),  constitutes  an  even  larger  commitment:  It  is  the  equivalent  of  having 
your  first  child. 

Appropriate  variants  include  the  number  of  spiral  cycles  of  development  increments  between 
the  anchor  points.  In  some  cases,  anchor  point  milestones  can  be  merged.  In  particular,  a 
project  deciding  to  use  a  mature  and  appropriately  scalable  fourth  generation  language  (4GL) 
or  product  line  framework  will  have  already  determined  its  choice  of  life  cycle  architecture 
by  its  LCO  milestone,  enabling  the  LCO  and  LCA  milestones  to  be  merged. 

Further  elucidation  and  discussion  of  the  anchor  point  milestones  is  deferred  to  Section  3. 

Spiral  Model  and  Incremental  Commitment:  Stud  Poker  Analogy 

A  valuable  aspect  of  the  original  application  of  the  spiral  model  to  the  TRW  Software  Pro¬ 
ductivity  System  was  its  ability  to  support  incremental  commitment  of  corporate  resources  to 
the  exploration,  definition,  and  development  of  the  system,  rather  than  requiring  a  large  out¬ 
lay  of  resources  to  the  project  before  its  success  prospects  were  well  understood  [Boehm  88]. 
These  decisions  are  codified  with  the  specific  guidelines  of  the  LCO  and  LCA. 

Funding  a  spiral  development  can  thus  be  likened  to  the  game  of  stud  poker.  You  can  put  a 
couple  of  chips  in  the  pot  and  receive  two  cards,  one  hidden  and  one  exposed,  along  with  the 
other  players  in  the  game.  If  your  cards  don’t  promise  a  winning  outcome,  you  can  drop  out 
without  a  great  loss.  If  your  two  cards  are  both  aces,  you  will  probably  bet  on  your  prospects 
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aggressively  (although  perhaps  less  so  if  you  can  see  the  other  two  aces  as  other  players’  ex¬ 
posed  cards).  In  any  case,  you  can  decide  during  each  round  whether  it’s  worth  putting  more 
chips  in  the  pot  to  buy  more  information  about  your  prospects  for  a  win  or  whether  it’s  better 
not  to  pursue  this  particular  deal,  based  on  the  information  available. 


Stud  Poker  Analogy 

•  Evaluate  alternative  courses  of  action 

-  Fold:  save  resources  for  other  deals 

-  Bet:  buy  at  least  one  more  round 

•  Use  incomplete  information 

-  Hole  cards:  competitive  situation 

-  Rest  of  deck:  chance  of  getting  winner 

•  Anticipate  futurspossibiiities 

-  Likeiihopd  that  next  betting  round  wiil  clarify  outcome 

•  Commit  incrementally  rather  than  all  at  once 

-  Call  only  the  most  recent  bet  ^  ^  ^  ^  ^  ^  ^ 

-  Raise  an  arnount  of  your  own  choice 


One  of  the  main  challenges  for  organizations  such  as  the  Department  of  Defense  (DoD),  is  to 
find  incremental  commitment  alternatives  to  its  current  Program  Objectives  Memorandum 
(POM)  process  which  involves  committing  to  the  full  funding  of  a  program  (putting  all  of  its 
chips  in  the  pot)  based  on  very  incomplete  early  information. 


2.6  Spiral  Invariant  6:  Emphasis  on  System  and  Life 
Cycle  Activities  and  Artifacts 

Spiral  Invariant  6  emphasizes  that  spiral  development  of  software-intensive  systems  needs  to 
focus  not  just  on  software  construction  aspects,  but  also  on  overall  system  and  life  cycle  con¬ 
cerns.  Software  developers  are  particularly  apt  to  fall  into  the  oft-cited  trap:  “If  your  best  tool 
is  a  hammer,  the  world  you  see  is  collection  of  nails.”  Writing  code  may  be  a  developer's 
forte,  but  it  stands  in  importance  to  the  project  as  do  nails  to  a  house. 

The  spiral  model’s  emphasis  on  using  stakeholder  objectives  to  drive  system  solutions,  and 
on  the  life  cycle  anchor  point  milestones,  guides  projects  to  focus  on  system  and  life  cycle 
concerns.  The  model's  use  of  risk  considerations  to  drive  solutions  makes  it  possible  to  tailor 
each  spiral  cycle  to  whatever  mix  of  software  and  hardware,  choice  of  capabilities,  or  degree 
of  productization  is  appropriate. 
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Avoids  premature  suboptimization  on 

hardware,  software,  or  deveibpment  considerations 


..^^,.1..  ;s\j. 


Example:  Order  Processing 


6a.  BeiaWeianiount  of  hardware  ancl  software  determined  in  each  cycle 
6b.  Relativeamount  of  capability  in  each  IHe.cycie  increment , 


6c.  Degree  of  productization  (alpha,  beta,  sbi1nk>wrap,  etc.) 
,  each  life  cycle  increment 

Models  excluded 


. 

operetional,  peiformaf^,^nd  cost  risks)  ^ 


Example:  “Order  Processing” 

A  good  example  is  the  Scientific  American  order  processing  system  sketched  in  Figure  5. 

The  software  people  looked  for  the  part  of  the  problem  with  a  software  solution  (their  “nail”), 
pounded  it  in  with  their  software  hammer,  and  left  Scientific  American  worse  off  than  when 
they  started. 


(minutes) 


BILLS,  LABELS,  REPORTS 
INVALID  INPUTS 


FIX  BY  EYEBALL^ 
KEYPUNCH 


IBM  360/30: 

CHECK  VALID  INPUTS 
UPDATE  MASTER  FILE 
GENERATE  BILLS, 
LABELS,  REPORTS 


NEW 

MASTER 

BILLS, 

LABELS, 

REPORTS 

INVALID 

INPUTS 


LOCATE  DECKS 
RECONCILE  WITH  FORMS  . 
KEYPUNCH  AND  REPLAC^ 
CARDS 


TRW 


Figure  5:  Scientific  American  Order  Processing 

Scientific  American’s  objectives  were  to  reduce  its  subscription  processing  system’s  costs, 
errors,  and  delays.  Rather  than  analyze  the  sources  of  these  problems,  the  software  house 
jumped  in  and  focused  on  the  part  of  the  problem  having  a  software  solution.  The  result  was 
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a  batch-processing  computer  system  whose  long  delays  put  extra  strain  on  the  clerical  portion 
of  the  system  that  had  been  the  major  source  of  costs,  errors,  and  delays  in  the  first  place.  As 
seen  in  the  chart,  the  business  outcome  was  a  new  system  with  more  errors,  greater  delays, 
higher  costs,  and  less  attractive  work  than  its  predecessor  [Boehm  81], 

This  kind  of  outcome  would  have  resulted  even  if  the  software  automating  the  tabulator- 
machine  functions  had  been  developed  in  a  risk-driven  cyclic  approach.  However,  its  Life 
Cycle  Objectives  milestone  package  would  have  failed  its  feasibility  review,  as  it  had  no 
system-level  business  case  demonstrating  that  the  development  of  the  software  would  lead  to 
the  desired  reduction  in  costs,  errors,  and  delays.  Had  a  thorough  business  case  analysis  been 
done,  it  would  have  identified  the  need  to  re-engineer  the  clerical  business  processes  as  well 
as  to  automate  the  manual  tab  runs.  Further,  as  shown  by  recent  methods  such  as  the  DMR 
Benefits  Realization  Approach,  the  business  case  could  have  been  used  to  monitor  the  actual 
realization  of  the  expected  benefits,  and  to  apply  corrective  action  to  either  the  business 
process  re-engineering  or  the  software  engineering  portions  of  the  solution  (or  both)  as  ap¬ 
propriate  [Thorp  98]. 

Hazardous  Spiral  Look-Alikes:  Logic-Only  00  Designs 

Models  excluded  by  Invariant  6  include  most  published  object-oriented  analysis  and  design 
(OOA&D)  methods,  which  are  usually  presented  as  abstract  logical  exercises  independent  of 
system  performance  or  economic  concerns.  For  example,  in  a  recent  survey  of  16  OOA&D 
books,  only  six  listed  the  word  “performance”  in  their  index,  and  only  two  listed  “cost.” 
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3  Anchor  Point  Milestones 


The  anchor  point  milestones  from  invariant  5  are 
Life  Cycle  Objectives  (LCO) 

Life  Cycle  Architecture  (LCA) 

Initial  Operational  Capability  (IOC) 

Since  these  milestones  [Boehm  96]  are  relatively  new  additions  to  the  spiral  development 
model,  they  are  covered  in  some  depth  in  succeeding  pages.  The  next  two  subsections  de¬ 
scribe  the  anchor  points  themselves  and  are  followed  by  a  discussion  of  how  an  “evolution¬ 
ary”  development  process  can  benefit  from  the  LCA  milestone.  Succeeding  sections  summa¬ 
rize  other  aspects  of  the  spiral  model  relevant  to  the  anchor  point  milestones,  such  as  their 
support  of  incremental  commitment  and  their  relation  to  the  Rational  Unified  Process  and  the 
use  MBASE  approach. 

3.1  Detailed  Descriptions 

Table  1  lists  the  major  features  of  the  LCO  and  LCA  milestones.  Unlike  most  current  soft¬ 
ware  milestones 

•  Their  focus  is  not  on  requirements  snapshots  or  architecture  point  solutions,  but  on  re¬ 
quirements  and  architectural  specifications  which  anticipate  and  accommodate  system 
evolution.  This  is  the  reason  for  calling  them  the  “Life  Cycle”  Objectives  and  Archi¬ 
tecture  milestones. 

•  Elements  can  be  either  specifications  or  executing  programs  with  data  (e.g.,  prototypes, 
COTS  products). 

•  The  Feasibility  Rationale  is  an  essential  element  rather  than  an  optional  add-on. 

•  Stakeholder  concurrence  on  the  milestone  elements  is  essential.  This  establishes  mu¬ 
tual  stakeholder  buy-in  to  the  plans  and  specifications,  and  enables  a  collaborative  team 
approach  to  unanticipated  setbacks  rather  than  an  adversarial  approach  as  in  most  con¬ 
tract  models. 

These  characteristics  explain  why  LCO  and  LCA  and  critical  to  success  on  projects,  and  thus 
why  they  are  able  to  function  successfully  as  anchor  points  across  many  types  of  software 
development. 

A  key  feature  of  the  LCO  milestone  is  the  need  for  the  Feasibility  Rationale  to  demonstrate  a 
viable  business  case  for  the  proposed  system.  Not  only  should  this  business  case  be  kept  up 
to  date,  but  also  it  should  be  used  as  a  basis  for  verifying  that  expected  benefits  will  actually 
be  realized,  as  discussed  in  the  “Order  Processing”  example  for  Invariant  6. 
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Table  1:  WinWin  Spiral  Anchor  Points  (with  risk-driven  level  of  detail  for  each 
element) 


Milestone 

Element 

Definition  of 

Operational 

Concept 


System 
Prototype(s) 
Definition  of 
System 
Requirements 


Definition  of 
System  & 
Software 
Architecture 


Definition  of 
Life-Cycle  Plan 


Feasibility 

Rationale 


Life  Cycle  Objectives  (LCO) 

Top-level  system  objectives  and  scope 

-  System  boundary 

-  Environment  parameters  and 
assumptions 

-  Evolution  parameters 
Operational  concept 

-  Operations  and  maintenance  scenarios 
and  parameters 

-  Organizational  life-cycle  responsibilities 
(stakeholders) 

Exercise  key  usage  scenarios 
Resolve  critical  risks 


Life  Cycle  Architecture  (LCA) 

Elaboration  of  system  objectives  and 
scope  of  increment 

Elaboration  of  operational  concept  by 
Increment 


Exercise  range  of  usage  scenarios 
Resolve  major  outstanding  risks 


Top-level  functions,  interfaces,  quality 
attribute  levels,  including: 

-  Growth  vectors  and  priorities 

-  Prototypes 

Stakeholders’  concurrence  on  essentials 


Top-level  definition  of  at  least  one  feasible 
architecture 

-  Physical  and  logical  elements  and 
relationships 

-  Choices  of  COTS  and  reusable  software 
elements 

Identification  of  infeasible  architecture  options 


Identification  of  life-cycle  stakeholders 

-  Users,  customers,  developers, 
maintainers,  interoperators,  general 
public,  others 

Identification  of  life-cycle  process  model 

-  Top-level  stages,  increments 


Elaboration  of  functions,  Interfaces, 
quality  attributes,  and  prototypes  by 
Increment 

-  Identification  of  TBD’s  (to-be- 
determined  Items) 

Stakeholders’  concurrence  on  their 
priority  concerns 

Choice  of  architecture  and  elaboration  by 
increment 

-  Physical  and  logical  components, 
connectors,  configurations, 
constraints 

-  COTS,  reuse  choices 

“  Domain-architecture  and 
architectural  style  choices 

Architecture  evolution  parameters 

Elaboration  of  WWWWWHH*  for  Initial 
Operational  Capability  (IOC) 

-  Partial  elaboration,  identification  of 
key  TBDs  for  later  Increments 


Top-level  WWWWWHH*  by  stage 

Assurance  of  consistency  among  elements 
above 

-  Via  analysis,  measurement,  prototyping, 
simulation,  etc. 


Assurance  of  consistency  among 
elements  above 

All  major  risks  resolved  or  covered  by  risk 
management  plan 


-  Business  case  analysis  for  requirements, 
feasible  architectures 


*WWWWWHH:  Why,  What,  When,  Who,  Where,  How,  How  Much 
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A  feature  distinguishing  the  LCA  milestone  from  the  LCO  milestone  is  the  need  to  have  all  of 
the  system’s  major  risks  resolved,  or  at  least  covered  by  an  element  of  the  system’s  risk  man¬ 
agement  plan.  For  large  systems,  passing  the  LCA  milestone  is  the  point  of  significant  esca¬ 
lation  of  staff  level  and  resource  commitments.  Proceeding  into  this  stage  with  major  risks 
unaddressed  has  led  to  disaster  for  many  large  projects.  Some  good  guidelines  for  software 
risk  assessment  can  be  found  in  [Boehm  89a,  Charette  89,  Carr  93,  Hall  98]. 

The  Initial  Operational  capability  (IOC)  is  the  first  the  users  will  see  of  a  functioning  system, 
so  getting  things  wrong  in  the  IOC  can  have  serious  consequences.  Greeting  users  with  a 
new  system  having  ill-matched  software,  poor  site  preparation,  or  poor  users  preparation  has 
been  a  frequent  source  of  user  alienation  and  project  failure. 

The  key  elements  of  the  IOC  milestone  are 

•  Software  preparation,  including  both  operational  and  support  software  with  appropriate 
commentary  and  documentation;  data  preparation  or  conversion;  the  necessary  licenses 
and  rights  for  COTS  and  reused  software,  and  appropriate  operational  readiness  testing. 

•  Site  preparation,  including  facilities,  equipment,  supplies,  and  COTS  vendor  support 
arrangements. 

•  User,  operator  and  maintainer  preparation,  including  selection,  teambuilding,  training 
and  other  qualification  for  familiarization,  usage,  operations,  or  maintenance. 

As  with  the  Pre-Ship  Testing  Example  given  with  Invariant  3,  the  IOC  milestone  is  risk- 
driven  with  respect  to  the  system  objectives  determined  in  the  LCO  and  LCA  milestones. 
Thus,  for  example,  these  objectives  drive  the  tradeoff  between  IOC  date  and  quality  of  the 
product.  These  will  differ  markedly  between  such  systems  as  the  safety-critical  Space  Shuttle 
Software  and  a  market-window-critical  commercial  software  product.  The  difference  be¬ 
tween  these  two  cases  is  narrowing  as  commercial  vendors  and  users  increasingly  appreciate 
the  market  risks  involved  in  buggy  products  [Cusumano  95]. 

3.2  Relationships  to  Other  Process  Models 

This  section  sketches  four  process  models  that  have  adopted  portions  of  the  spiral  model  or 
extended  the  spiral  model. 

Evolutionary  Development 

All  too  often,  a  project  will  be  started  on  an  evolutionary  development  approach  based  on  a 
statement  such  as,  “We’re  not  sure  what  to  build,  so  let's  throw  together  a  prototype  and 
evolve  it  until  the  users  are  satisfied.”  This  approach  is  insensitive  to  several  risks  corre¬ 
sponding  to  the  set  of  assumptions  for  a  successful  evolutionary.  These  assumptions  are: 

1.  The  initial  release  is  sufficiently  satisfactory  to  key  system  stakeholders  that  they  will 
continue  to  participate  in  its  evolution. 
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2.  The  architecture  of  the  initial  release  is  scalable  to  accommodate  the  full  set  of  system 
life  cycle  requirements  (e.g.,  performance,  safety,  security,  distribution,  localization). 

3.  The  operational  user  organizations  are  sufficiently  flexible  to  adapt  to  the  pace  of 
system  evolution 

4.  The  dimensions  of  system  evolution  are  compatible  with  the  dimensions  of  evolving- 
out  the  legacy  systems  it  is  replacing. 

Without  some  initial  attention  to  user  needs,  as  required  for  LCO  and  LCA,  the  prototype 
may  be  so  far  from  the  users’  needs  that  they  consider  it  a  waste  of  time  to  continue.  As  dis¬ 
cussed  above,  it  will  be  risky  to  proceed  without  a  life  cycle  architecture  to  support  evolution. 
Another  risk  is  “information  sclerosis”:  the  propensity  for  organizations  to  lock  into  opera¬ 
tional  procedures  making  it  difficult  to  evolve  toward  better  capabilities  [Boehm  88].  A  final 
frequent  risk  is  that  legacy  systems  are  often  too  inflexible  to  adapt  to  desired  directions  of 
evolution.  In  such  cases,  a  preferable  process  model  is  incremental  development,  with  the 
increments  determined  by  the  ease  of  evolving-out  portions  of  the  legacy  system. 

Rational  RUP  Phases 

Versions  of  Figure  6  appear  in  the  three  main  books  on  the  Rational  Unified  Process  (RUP) 
[Royce  98,  Kruchten  98,  Jacobson  99].  It  shows  the  relations  between  LCO,  LCA,  and  IOC 
milestones  and  the  RUP  phases  of  Inception,  Elaboration  Constraction,  and  Transition.  It 
also  illustrates  that  the  requirements,  design,  implementation,  and  deployment  artifacts  are 
incrementally  grown  throughout  the  phases.  As  indicated  in  Variant  3b,  the  size  of  the  shaded 
bars  (the  relative  efforts  for  Requirements,  Design,  Implementation,  and  Deployment)  will 
vary  from  project  to  project. 


Engineering  Stage 

Production  Stage 

Inception  Elaboration 

Construction  Transition 

Feasibility  Architecture  Usable  Product 

Iterations  Iterations  Iterations  Releases 


RATIONAL 

Sortwarc  Corporalion 


Figure  6:  Anchor  Points  and  the  Rational  RUP  Phases 
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WinWin  Spiral  Model 

The  original  spiral  model  [Boehm  88]  began  each  cycle  of  the  spiral  by  performing  the  next 
level  of  elaboration  of  the  prospective  system’s  objectives,  constraints  and  alternatives.  A 
primary  difficulty  in  applying  the  spiral  model  has  been  the  lack  of  explicit  process  guidance 
in  determining  these  objectives,  constraints,  and  alternatives.  The  Win-Win  Spiral  Model 
(Figure  7)  [Boehm  94]  uses  the  Theory  W  (win-win)  approach  [Boehm  89b]  to  converge  on  a 
system’s  next-level  objectives,  constraints,  and  alternatives.  This  Theory  W  approach  in¬ 
volves  identifying  the  system’s  stakeholders  and  their  win  conditions,  and  using  negotiation 
processes  to  determine  a  mutually  satisfactory  set  of  objectives,  constraints,  and  alternatives 
for  the  stakeholders. 


Figure  7:  The  WinWin  Spiral  Model 


In  particular,  as  illustrated  in  the  figure,  the  nine-step  Theory  W  process  translates  into  the 
following  spiral  model  extensions  (numbered  as  in  the  figure): 

1.  Determine  Objectives.  Identify  the  system  life-cycle  stakeholders  and  their  win  condi¬ 
tions.  Establish  initial  system  boundaries  and  external  interfaces. 

2.  Determine  Constraints.  Determine  the  conditions  under  which  the  system  would  pro¬ 
duce  win-lose  or  lose-lose  outcomes  for  some  stakeholders. 

3.  Identify  and  Evaluate  Alternatives.  Solicit  suggestions  from  stakeholders.  Evaluate 
them  with  respect  to  stakeholders’ win  conditions.  Synthesize  and  negotiate  candidate 
win-win  alternatives.  Analyze,  assess,  and  resolve  win-lose  or  lose-lose  risks. 

Commit.  Record  Commitments,  and  areas  to  be  left  flexible,  in  the  project’s  design  record 
and  life  cycle  plans. 

4-7.  Cycle  Through  the  Spiral.  Elaborate  the  win  conditions,  evaluate  and  screen  alterna¬ 
tives,  resolve  risks,  accumulate  appropriate  commitments,  and  develop  and  execute 
downstream  plans. 
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MBASE  Electronic  Process  Guide 

The  Model-Based  (System)  Architecting  and  Software  Engineering  (MBASE)  approach 
[Boehm  99a,  Boehm  99b,  Boehm  00b],  provides  more  detailed  definitions  of  the  anchor  point 
milestone  elements  [Boehm  00b],  and  a  process  guide  for  deriving  them.  LCO  and  LCA  are 
both  described  as  consisting  of  Operational  Concept  Definition,  Requirements  Definition, 
Architecture  Definition,  Life  Cycle  Plan,  Key  Prototypes,  and  Feasibility  Rationale.  Each  of 
these  artifacts  is  described  in  detail. 

The  MBASE  Electronic  Process  Guide  (EPG)  [Mehta  99]  was  developed  using  the  Electronic 
Process  Guide  support  tool  provided  by  the  SEI  [Kellner  98].  It  uses  Microsoft  Access  to 
store  the  process  elements,  using  an  Activities-Artifacts-Agents  model,  and  translates  the  re¬ 
sults  into  hyperlinked  HTML  for  web-based  access.  Four  sorts  of  windows  appear;  diagrams, 
outlines,  descriptions,  and  templates.  Figure  8  shows  the  top-level  outline  of  activities,  arti¬ 
facts,  and  agents.  Figure  9  shows  the  diagram  for  the  Inception  Phase  of  the  process.  A  click 
on  any  element  of  that  diagram  brings  up  a  structured  description  of  that  element.  In  the  Fig¬ 
ure,  the  “Risk  Driven  Analysis”  section  was  clicked  to  bring  up  the  outline  and  description 
shown  in  Figure  10. 

The  top  section  of  the  outline  window  in  Figure  1 1  places  Risk  Driven  Analysis  within  its 
context  of  the  Inception  Phase,  parallel  to  the  Elaboration  Phase,  with  both  being  part  of  the 
MBASE  577a  Process  (used  for  Computer  Science  course  577a  at  USC).  The  other  activities 
of  the  Inception  Phase  are  also  listed  and  can  be  fetched  by  clicking  their  names  in  the  out¬ 
line.  Below  the  process  outline  is  the  outline  of  the  Risk  Driven  Analysis  description  shown 
to  the  right.  Clicking  there  on  the  “Outputs”  item  scrolls  the  description  to  its  Outputs  sec¬ 
tion,  which  is  shown  in  Figure  10.  Clicking  an  artifact  name  like  “Operational  Concept  De¬ 
scription”  brings  up  another  structured  description;  in  this  case  one  containing  a  reference  to 
an  active  template  document  for  the  artifact.  Clicking  in  the  fields  of  this  document  lets  the 
user  enter  the  values  and  descriptions  appropriate  to  his  or  her  own  particular  project. 
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Figure  8  EPG  Top-Level  Outline  of  Activities,  Artifacts,  and  Agents 


Figure  9  EPG  Diagram  of  the  Inception  Phase 
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Activities: 

B  •  M0ASE  577a  Pioc«ss 
0  - Inctption  Pha« 
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■  •  •  •  Identify  Critical  Risks 
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0-- Domain  Analysis 
:  0*  Success  Aria  lysis 
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Activity: 

Risk-driven 

Analysis 

•  Overview 

•  Purpose 

•  Decomposition 
p  Description 

•  Tools  and  Techniques 

•  Pitfalls 

•  Participation 

•  Agertt  Responsibilities 
^  Inputs 

^  Outputs 

•  Behavior 

•  Effort  Guidelines 


101  Risk-driven  Analysis 


Overview 

System  analysis  driven  by  risk 

Purpose 

The  objectives  of  this  activity  are: 

»  To  identify  the  most  critical  risk  factors  In  the  project 

■  To  assess  the:impact  of  the  risks  associated  with  the 
project 

■  To  prepare  a  risk  mitigation  plan  for  the  most  critical  risks 

Decomposition 

The  activity  Risk-driven  Analysis  is  decomposed  into  the  following; 

“  Identify  Frequent  Risks 

■  Develop  Prototype 

■  Identify  Critical  Risks 

Description 

MBASE  is  a  risk-driven  process  framework  and  every  process 
based  on  MBA5E  adopts  an  early  risk  assessment  and  resolution 
approach.  During  Inception  critical  system  risks  should  be 
Identified  and  resolved  based  on  their  impact  on  the  system 
life-cycle 

Tools  and  Techniques 

Software  Risk  Taxonomyj 
Project  Simplifiers  and  Complicators 


Pitfalls 


The  common  pitfalls  during  this  activity  are; 

■  Not  identifying  the  major  technological  risks  during 
Inception 


Figure  10  EPG  Outline  and  Description  of  Risk  Driven  Analysis 


Partidpating  Agent 

^JUppUfL  ribK.  MJUJydUUn  dL 

performing  agents 

Performing  Agent 

Identify  and  resolve  proje 

Inputs 

The  following  artifacts  are  inputs  to  the  RIsk-drh 


System  and  Software  Architetture 
Description 


Outputs 

The  following  artifacts  are  outputs  to  the  Risk-di 

Artifact  Sourct 

Feasibility  Rationale  Description  projecl 

Operational  Concept  Description  Project 


iBehavior 

Figure  11  The  “Outputs”  Section  of  the  Description  on  the  Right  of  Figure  1 0. 
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4  Summary 


This  paper  has  presented  a  preliminary  definition  of  the  spiral  development  model  and  char¬ 
acterized  the  model  further  by  presenting  a  set  of  six  “invariant”  attributes.  That  is,  six  prop¬ 
erties  which  every  spiral  development  process  must  incorporate.  These  are  listed  in  Table  2 
along  with  a  notion  of  why  they  are  necessary  and  a  few  characteristics,  called  “variants,” 
that  may  vary  from  one  spiral  process  model  to  another. 

Numerous  process  models  with  development  structured  in  a  cyclic  series  of  efforts  can  ap¬ 
pear  to  be  spiral  models  and  yet  violate  one  or  more  invariants  and  subsequently  fail.  These 
are  listed  in  Table  3,  together  with  a  reference  to  further  discussion  in  the  text. 

The  second  part  of  the  paper  was  devoted  to  the  anchor  point  milestones  of  Invariant  5.  These 
milestones — ^Life  Cycle  Objectives  (LCO),  Life  Cycle  Architecture  (LCA),  and  Initial  Oper¬ 
ating  Capability  (IOC) — ^provide  concrete  artifacts  to  drive  the  project  toward  completion. 
They  also  provide  for  comparison,  evaluation,  and  planning  between  projects.  The  discussion 
concluded  with  the  Win  Win  spiral  model  and  MBASE,  which  assist  in  the  use  of  the  anchor 
point  milestones. 

This  paper  is  intended  as  a  sufficient  characterization  of  the  spiral  development  model  to  dis¬ 
tinguish  it  from  other  project  process  models.  Although  not  within  itself  a  full  description  and 
user's  guide  for  the  spiral  development  model,  it  is  a  suitable  basis  for  such  further  works. 
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Table  2:  Invariants  of  Spiral  Processes:  Name,  Rationale,  and  Variants 


Invariant  {&  example} 

1 .  Concurrent  rather  than 
sequential  determination  of 
key  artifacts--Ops  Concept, 
Requirements,  Plans,  Design, 
Code-'in  each  spiral  cycle 

{One-  Second  Response  Time} 

2.  Each  cycle  considers 
critical  stakeholder  objectives 
and  constraints,  product  and 
process  alternatives,  risk 
identification  and  resolution, 
stakeholder  review,  and 
commitment  to  proceed 

(Windows-only  COTS} 

3.  Level  of  effort  on  each 
activity  within  each  cycle 
driven  by  risk  considerations 
(Pre-ship  Testing} 


4.  Degree  of  detail  of  artifacts 
produced  in  each  cycle  driven 
by  risk  considerations 

(GUI  layouts} 

5.  Managing  stakeholder  life 
cycle  commitments  via  the 
LCO,  LCA,  and  IOC  anchor 
point  milestones 

(Stud  Poker  Analogy} 


6.  Emphasis  on  system  and 
life  cycle  activities  and 
artifacts  rather  than  software 
and  initial  development 
activities  and  artifacts 

(Order  Processing} 


Why  invariant  Variants 

Avoids  premature  la.  Relative  amount  of  each 

sequential  commitments  artifact  developed  in  each 

cycle 

1  b.  Number  of  concurrent 
mini-cycles  in  each  cycle 


Avoids  commitment  to  2a.  Choice  of  risk  resolution 
alternatives  that  are  risky  or  techniques:  prototyping, 
unacceptable  to  simulation,  modeling, 

stakeholders  benchmarking,  reference 

Avoids  wasting  effort  on  checking,  etc. 
unusable  alternatives  2b.  Level  of  effort  on  each 

activity  within  each  cycle 


Avoids  too  little  or  too  much  3a.  Choice  of  methods  used 
of  each  activity  to  pursue  activities: 

Avoids  overkill  or  belated  MBASE/WinWin,  Rational 
risk  resolution  RUP ,  JAD,  QFD,  ESP, . . . 

3b.  Degree  of  detail  of 
artifacts  produced  in  each 
cycle 


Avoids  too  little  or  too  much 
of  each  artifact 

Avoids  overkill  or  belated 
risk  resolution 

Avoids  analysis  paralysis, 
unrealistic  expectations, 
requirements  creep, 
architectural  drift,  COTS 
shortfalls  or 
incompatibilities, 
unsustainable 
architectures,  traumatic 
cutovers,  useless  systems 

Avoids  premature 
suboptimization  on 
hardware,  software,  or 
development 
considerations 


4a.  Choice  of  artifact 
representations  (SA/SD, 

UML,  MBASE,  formal  specs, 
programming  languages,  etc.) 

5a.  Number  of  spiral  cycles 
or  increments  between 
anchor  points 
5b.  Situation-specific 
merging  of  anchor  point 
milestones 


6a.  Relative  amount  of 
hardware  and  software 
determined  in  each  cycle 

6b.  Relative  amount  of 
capability  in  each  life  cycle 
increment 

6c.  Degree  of  productization 
(alpha,  beta,  shrink-wrap, 
etc.)  of  each  life  cycle 
increment 
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Table  3:  Hazardous  Spiral  Look-Alikes 


Hazardous  Spiral  Look-Alike 

Invariant 

Examples 

Incremental  sequential  waterfalls  with 
significant  COTS,  user  interface, 
or  technology  risks 

1 

One  Second  Response  Time 

Violation  of  Waterfall  Assumptions 

Sequential  spiral  phases  with  key 
stakeholders  excluded  from 
phases 

2 

Windows-oniy  COTS 

Excluding  Key  Stakeholders 

Risk-insensitive  evolutionary  or 
incremental  development 

3 

Pre-ship  Testing 

Risk  Insensitivity 

Section  3.3:  Risks  of  Evolutionary 
Development 

Impeccable  spiral  plan  with  no 

commitment  to  managing  risks 

3 

(special  case  of  the  above) 

Insistence  on  complete  specifications 
for  COTS,  user  interface,  or 
deferred-decision  situations 

4 

Risk  of  Precise  Specification 

Evolutionary  development  with  no  life- 
cycle  architecture 

5 

Section  3.3:  Risks  of  Evolutionary 
Development 

Purely  logical  object-oriented  methods 

6 

Logic-Only  00  Designs 

with  operational,  performance,  or 
cost  risks 
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